chore: first spike of submitting 2 enhancements #1
Conversation
| e.g. the pipeline with boot apps could be something like this... | ||
|
|
||
| ``` | ||
| jx step helmfile --selector phase=pre-ingress |
There was a problem hiding this comment.
I haven't used boot yet, but the this phase selector seems odd. Would a more simple solution be to use a separate helmfile for each phase?
There was a problem hiding this comment.
we could go either way on this; I initially started with separate files. Then after thought + experimentation moved back to single file again.
My main reasoning is; the use of the phase selector on the helmfile is a total implementation detail of the boot pipeline. Most end users + tools don't need to care at all about phases and it only really affects a couple of charts (ingress / vault / cert manager / external dns really).
So rather than forcing all users + tools to have to look at N files to grok what apps are being installed; its much simpler to have them all in 1 file.
There was a problem hiding this comment.
Ah I think I see. So, likely most charts wouldn't have a selector... or just the same selector. Is this a built in helmfile concept? What happens if I depend on a chart that's in a different selector? Guessing I shouldn't do that, but might happen.
In the end, I see your point though 👍
There was a problem hiding this comment.
the PoC made this much simpler btw - most charts ignore the phase stuff and just get added to the apps/helmfile.yaml - otherwise some special charts (e.g. nginx-ingress are configured OOTB to use phase system which goes into system/helmfile.yaml - so hopefully this lets us have different phases, but also keep things simple for most users.
There was a problem hiding this comment.
details of how the current PoC works here: https://github.com/jenkins-x/enhancements/blob/master/proposals/2/docs/how-it-works.md#how-it-works
separate helmfiles was so much easier btw (then you can cd apps && helmfile sync without worrying about selectors or whatever
There was a problem hiding this comment.
Nice, that's good and clear separation. I like it!
| so it'd be nice to have a simple app model where anyone can add any systems/charts to any namespace at any point in the flow before we setup the dev/staging/production environment in the traditional way. | ||
|
|
||
|
|
||
| ## Proposal |
There was a problem hiding this comment.
The way we manage teams currently (using the old way, with static Jenkins and all that) is that we have 1 cluster and each team has their own Jenkins and environments so they don't step on each other's toes. With this method, we do have sort of a "cluster team" in order to install cluster tools like prometheus, logging, etc.
Would this proposal support this sort of use case? Seems like each team would have their own boot and then we would have a "cluster tools" boot that could install the shared cluster tools.
There was a problem hiding this comment.
I'll try improve the docs in the PR to show some samples of mult-team.
if teams are sharing the same cluster, its probably easiest to have a shared install of common things (lighthouse / tekton / nexus / prometheus / ingress / cert manager / vault et al), then have a few namespaces / CRDs per team.
We can store the team specific configuration in a team specific directory and let the folks in the teams be OWNERS of those folders; so that we can have 1 git repository to setup all the infrastructure + teams without having to have 1 git repo per team.
There was a problem hiding this comment.
Whaaaaaat!?! Please please show me the way! This sounds amazing! This quarter we are hoping to jump over to boot and all the new toys. This would be a very good time to do such a thing.
I think our main hope or "requirement" was to have teams have their own environment repos so one teams deployment wouldn't disrupt another's. We can also setup team quotas and other nifty things.
There was a problem hiding this comment.
@polothy I'll try get a demo going soon. All the heavy lifting is done now at least ;) Here's the current docs: https://github.com/jenkins-x/enhancements/tree/master/proposals/2/docs
There was a problem hiding this comment.
I'll re-review when I can. This is looking very promising though, this is exactly what we need to help manage the cluster and teams.
which replaces the previous google doc and consolidates the issue + doc together into a single PR jenkins-x/jx#6442
splitting into separate pages and adding a guide on how it works
|
I'm gonna go ahead and merge this - we can keep PR'ing updates to the enhancements as things change |
which replaces the previous google doc and consolidates the issue + doc together into a single PR
jenkins-x/jx#6442